The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile communication networks. IP multimedia services can provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in FIG. 1, control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer or user plane, and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A Gateway GPRS Support Node (GGSN) 2a acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a which operates over the Control Layer 4 and the Connectivity Layer 1, and a service network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1, as well as network nodes (including Call/Session Control Functions (CSCFs) 5) which operate as SIP proxies within the IMS in the Control Layer 4.
The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality.
Modern telecommunication systems may incorporate a Policy and Charging Control (PCC) architecture. A PCC architecture for the IMS is described in 3GPP TS 23.203 V7.9.0 (and later versions) in respect of packet flows in an IP-CAN session established by a user equipment UE through a 3G telecommunications system. The particular architecture comprises: a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The PCRF behaves as a Policy Decision Point (PDP) or Policy Server (PS), and the PCEF behaves as a Policy Enforcing Point (PEP). Whilst the PCRF can be implemented as a standalone node, the PCEF is preferably co-located within an Access Gateway (AG) such as the GGSN in a GPRS core network. Such an architecture is illustrated schematically in FIG. 2, where BSS represents the Base Station Subsystem of a radio access network (e.g. GERAN or UTRAN). In a CDMA network, the AG may be a Packet Data Serving Node (PDSN). Related architectures are provided for 3GPP2 networks and TISPAN Next Generation Networks.
In the case of a PCEF co-located with a GGSN, the GGSN is responsible for inspecting data packets associated with data flows originating at and/or terminating in a user terminal served by the GGSN. In the case of a subscriber roaming into a “visited” network, the GGSN assigned to route data packets related to the (roaming) terminal may be located in the subscriber's home network.
When a User Equipment (UE) initiates a data session, an IP address is assigned to it by an appropriate AG. The AG provides this IP address, together with, for example, an NAI, IMSI, or MSISDN, to the Policy Server which in turn downloads into the AG one or more policy rules to be applied to the data session. When the UE communicates with an Application Function (AF), the AF may provide session details to the Policy Server. When the UE subsequently requests connectivity for the service provided by the AF, the AG informs the PS, which downloads into the AG policy rules for the connection(s) required. A policy rule may include a Service Data Flow (SDF) which consists of a standard IP 5-tuple (source IP address and port number, destination IP address and port number, protocol). Such a rule identifies a particular packet flow to the AG.
The interface between the AF and the PCRF is the Rx interface, specified in 3GPP TS 29.214. The interface between the PCRF and the PCEF is the Gx interface, specified in 3GPP TS 29.212.
In a 3GPP network, the AF may be a Proxy Call Session Control Function, P-CSCF, or another kind of application server to which the UE establishes an application communication via bearer(s) set up via IP-CAN session(s) through the AG.
Charging for IMS services utilises charging data generated using SIP signalling and SDP content received by the IMS node/s during the session negotiation. This approach enables value-based charging models rather than cost-based charging models to be employed, i.e. charging is based upon the value of a service to a user rather than directly on the cost to the operator to provide that service. However, for pure peer-to-peer services for which no application server or media proxy are present in the user plane, the service-based charging model has a weakness that might expose the network operators to fraud. This weakness arises because the IMS core, e.g. the P-CSCF, has no knowledge of the user plane traffic. Consider for example the case where a user signals to the IMS core that it wishes to share a picture with a peer user. The core anticipates that such a picture will have a (relatively small) limited size corresponding to a typical picture, and in turn signals to the user plane that the user should be allowed to exchange the picture. However, the user then sends an entire movie consisting of many GBytes to the peer user across the user plane. This may be allowed by the AG (e.g. GGSN) as, at the user plane level, the user has a subscription that allows unlimited data transfer and the Online Charging System (OCS) is unaware of any restrictions at the IMS level. The IMS core has no mechanism for preventing or even knowing about this fraudulent use, and only charges the user for a picture exchange.
It will be appreciated that current IMS standards are primarily intended to police traffic based upon bandwidth rather than volume. It will also be appreciated that, whilst a solution to the problem might be to implement volume policing at a Media Resource Function Processor (MRFP), this requires the implementation of a dedicated node through which traffic must pass.
It is also possible to achieve volume policing by configuring the Online Charging System to set limits on the volume of a certain type of traffic in the GGSN, for example data flows marked with a certain rating group received over the Gx interface. The online charging system will in this case only allow a certain amount of data of this type within a PDP context to be reported over the Gy interface before no further credit reservation is granted. Further data transport of this type is then prevented by GGSN. These mechanisms are specified in 3GPP TS23.203, TS29.211, TS29.212, TS29.213, TS29.214, 32.299 and 32.251. A problem with this approach, from an IMS service charging point of view, is that an IMS Application Function is not in control. This results in a number of complications, namely:                When a data flow is stopped the IMS core will not know if this was due to a volume limit being reached or to some other reason, for example a radio bearer failure. The IMS core cannot therefore report the reason to the terminal or to IMS customer care.        The solution is static and cannot take into consideration dynamic values received during session negotiation, for example negotiated file size. This information is not known to the OCS.        The solution depends on bearer charging, which creates a strong dependency between IMS service charging and bearer charging, which is undesirable from a maintenance appoint of view. This is particularly problematic when the IMS and bearer networks are provided by different operators, or by different business units of the same operator, or in roaming scenarios.        The solution cannot take into consideration IMS subscription differentiation. For example, an IMS “Gold” subscriber may be entitled to send larger files than an IMS “Silver” subscriber. This must be controlled by the IMS Application Function, since the bearer layer OCS is only aware of the bearer subscription. There is no simple correlation between an IMS subscription and a bearer subscription.        Bearer charging may not be under direct control of the IMS operator, particularly in the so-called “local breakout” case. The GGSN/PCEF in this case belongs to an operator other than the IMS operator, requiring very complex inter-operator agreements to make the solution feasible.        